Computer Graphics techniques for rendering a three-dimensional (3D) scene aims at drawing the 3D scene on a display device such as a computer screen, a television, a projector, . . . . Rendering a 3D scene is also referred to as 3D rendering.
Computer Graphics techniques for 3D rendering rely on hardware and software components that interact one each other's, and these components form an architecture dedicated to 3D rendering. The main hardware component of this architecture is the Graphic Card (GC) that is an accelerator designed to make some type of calculation faster. The GC is specialized in graphics computations such as converting a triangle into pixels. The GC comprises one or more Graphic Processing Units (GPUs); a GPU is a chip that performs the graphics computations of the GC. The GC can be connected to one or several display devices that display the result of the 3D rendering. Instructions to the GC and the GPU are sent through a Graphic Library (GL) that is a computer program library designed to aid in rendering computer graphics to a monitor. The GL is executed (or run) by the Central Processing Unit (CPU) of the computer hosting the GC. The two most famous GL are DirectX© and OpenGL©. In practice, the GL is not written by the hardware manufacturer, but rather by a third party that will developed the GL in accordance with the hardware specifications provided by the hardware manufacturer. A Render Engine (RE) is a framework that takes a 3D scene as an input and draw it to the screen with the use of one or more GC (in case of Multi Graphic Card rendering). The 3D scene is created by an application that uses the RE framework. The RE translates information provided by the application into Graphics Resources (GR). A GR is an object furnished by the GL on which operations can be performed such buffers, textures . . . Graphic Driver (GD), is a computer program that provides an interface to allow communications between the Operating System (OS) and the GC. In practice, GD are provided by GC manufacturers.
Multi GC rendering is the ability for an application to render a scene with the use of several GCs, plugged in on a same motherboard. Despite Multi GC principles are recent, only few applications use it because it involves a lot of complexity in the RE framework.
There are two common techniques to achieve multi Graphic Card rendering. Both rely on the Graphic Driver work and not on the Render Engine framework. The first technique uses SLI™ that was developed by nVIDIA™ or CrossFire™ that was developed by AMD™. Basically, when the RE of an application is rendering one frame, the RE uses the GL as if there was only one GC inside the computer. The RE is not aware that there are several GCs. The GD receives the orders and spread them to the GC. This illustrated on FIG. 1 that shows an example of a computer with two GCs wherein one GC renders the upper part of the screen and the second GC renders the bottom part. The RE receives from the application orders that are translated into GR (e.g. buffer, textures . . . ) received by the GL, which in turn sends orders for one GC. The GD managing the two cards (GC1, GC2) creates orders for the two GC using the SLI™/CrossFire™ technologies so that each GPU of each GC (GPU 1 of GC1, GPU2 of GC2) knows what information to process.
The second technique is based on the first one and is referred to as Mosaic mode. The Mosaic mode describes the ability to render at a higher resolution, using the display driver to spread the result to multiple screens. The combination of the Mosaic mode with the first techniques discussed above provides the capability for each GC to handle a separate display.
These first and second techniques are mostly used in game applications to improve performances or in flying simulator to output to more than one display with reasonable performances.
In addition to these two techniques, another technique provides specific Multi GCs by exposing rendering features by the GL. This technical is however experimental and not exploited by the hardware and software manufacturers.
These techniques of multi GCs rendering suffers several drawbacks. The first one is that they are limited to specific scenarios: the Mosaic mode for multiscreen rendering and SLI™/CrossFire™ for video games. Indeed, these techniques rely on the GD capabilities to dispatch orders to the GCs; however, the GD do not know at each time all the information required for performing the dispatch so that these solutions apply on few scenarios retained by the application developers. For instance, in a non-retained scenario only one GC is used; the application cannot benefit of the computing resources of the other GCs.
Another limitation is that these techniques are limited to one point of view on the rendered 3D scene. Hence, it is not possible to exploit the computing resources of the GPU for computing in parallel several viewpoints, which would improve the display speed of the 3D scene when changing of viewpoint.
A further limitation is that it is not possible to address a particular order to a particular GC, and it is not possible to expose this particular order to the RE. As explained above, the RE is not aware that there are several GCs.
Within this context, there is still a need for an improved management of multiple GCs. Notably, the GCs allow to render a 3D scene with multiple viewpoints on several display devices.